approved deletion of
protracker (Amiga screenshot)
approved deletion (despite bogus reason) of
phylip (logo not screenshot, reason not translatable from Spanish)
rejected deletion of
tora/bsdgames/unity (bogus reason)
Administration
Debian:
redirect 2 users to support channels,
redirect 1 person to the mirrors team,
investigate SMTP TLS question,
fix ACL issue,
restart dead exim4 service
Debian mentors:
service restarts,
security updates & reboot
Debian QA:
deploy my changes
Debian website:
release related rebuilds,
rebuild installation-guide
Debian wiki:
whitelist several email addresses,
whitelist 1 domain
Debian package tracker:
deploy my changes
Debian derivatives census:
deploy my changes
Openmoko:
security updates & reboots.
Communication
Help with the live coverage of
the Debian stretch release
rejected deletion (despite valid reason) of
borgbackup (no other screenshots)
rejected deletion of
synaptic (garbage in reason field)
Administration
Debian:
discuss mail bounces with a hoster,
check perms of LE results,
add 1 user to a group,
re-sent some TLS cert expiry mail,
clean up mail bounce flood,
approve some debian.net TLS certs,
do the samhain dance thrice,
end 1 samhain mail flood,
diagnose/fix LDAP update issue,
relay DebConf cert expiry mails,
reboot 2 non-responsive VM,
merged patches for debian.org-sources.debian.org meta-package,
deleted
osmose-emulator (6 screenshots of non-free games)
rejected
xserver-xorg-video-amdgpu (drivers have no UI),
eom (includes image of offensive historical figure),
synaptic (includes non-free background image),
osmose-emulator (6 screenshots of non-free games)
and
libomxil-bellagio0-components-xvideo (borked upload)
approved deletion of
xserver-xephyr (includes image of non-free OS),
perforate (image of the homepage)
and
openvas/lv2core (not screenshots)
rejected deletion of
vkeybd (junk in reason field)
Administration
Debian systems:
quiet a logrotate warning,
investigate issue with DNSSEC and alioth,
deploy fix on our first stretch buildd,
restore alioth git repo after history rewrite,
investigate iptables segfaults on buildd
and
investigate time issues on a NAS
Debian derivatives census:
delete patches over 5 MiB,
re-enable the service
Debian wiki:
investigate some 403 errors,
fix alioth KGB config,
deploy theme changes,
close a bogus bug report,
ping 1 user with bouncing email,
whitelist 9 email addresses
and
whitelist 2 domains
Debian QA:
deploy my changes
Debian mentors:
security upgrades
and
service restarts
Openmoko:
debug mailing list issue,
security upgrades and reboots
Debian website:
Remove old unused and not working website hosting sponsor functionality
(1234567),
use correct SSL CA cert store,
fix and https links to debian.ch and
fix HTML entity escaping in the mirrors list
(12)
rejected
hotssh (artefacts in screenshot),
libsixel-bin (copied from elsewhere),
spectrwm (not a screenshot) and
geeqie (worse version of accepted image)
approved deletion (despite bogus reason) of
snmp (screenshots site not a support forum, was a diagram not a screenshot)
rejected deletion of
kupfer (we do not remove old versions),
vlc (external UI in the screenshot is minimal),
vokoscreen/fonts-ecolier-lignes-court (garbage in reason field),
aptitude (discussing non-English screenshots with Christoph Haas),
hydra-gtk (greetings are not valid reasons) and
oxygen-icon-theme (the screenshot is not a reCAPTCHA)
Administration
Debian systems:
apply a patch to userdir-ldap,
ask a local admin to reset a dead powerpc buildd,
remove dead SH4 porterboxen from LDAP,
fix perms on www.d.o OC static mirror,
report false positives in an an automated abuse report,
redirect 1 student to FAQs/support/DebianEdu,
redirect 1 event organiser to partners/trademark/merchandise/DPL,
redirect 1 guest account seeker to NM,
redirect 1 @debian.org desirer to NM,
redirect 1 email bounce to a changes@db.d.o user,
redirect 2 people to the listmasters,
redirect 1 person to Debian Pure Blends,
redirect 1 user to a service admin and
redirect 2 users to support
Debian packages site:
deploy my ports/cruft changes
Debian wiki:
poke at HP page history and advise a contributor,
whitelist 13 email address,
whitelist 1 domain,
check out history of a banned IP,
direct 1 hoster to DebConf17 sponsors team,
direct 1 user to OpenStack packaging,
direct 1 user to InstallingDebianOn and h-node.org,
direct 2 users to different ways to help Debian and
direct 1 emeritus DD on repository wiki page reorganisation
Debian QA:
fix an issue with the PTS news,
remove some debugging cruft I left behind,
fix the usertags on a QA bug and
deploy some code fixes
Debian mentors: security upgrades and service restarts
What happened in the Reproducible
Builds effort between Sunday
December 4 and Saturday December 10 2016:
Toolchain development and fixes
Anders Kaseorg opened a pull
request to asciidoc
upstream, to make it generate reproducible documentation. (#782294)
Bugs filed
Chris Lamb:
Reviews of unreproducible packages
47 package reviews have been added, 84 have been updated and 3 have been
removed in this week, adding to our knowledge about identified
issues.
1 new issue type has been added: lessc_captures_build_path
Weekly QA work
During our reproducibility testing, some FTBFS bugs have been detected and
reported by:
Chris Lamb (8)
diffoscope development
Chris Lamb fixed a division-by-zero in the progress bar, split out
trydiffoscope into a separate package, and made some performance enhancements.
Maria Glukhova fixed build issues with Python 3.4
strip-nondeterminism development
Anders Kaseorg added support for .par files, by allowing them to be
treated as Zip archives; and Chris Lamb improved some documentation.
reprotest development
Ximin Luo added the ability to vary the build time using
faketime, as well as other code
quality improvements and cleanups.
He also discovered a little-known fact about faketime - that it also modifies
filesystem timestamps by default. He submitted a PR
to libfaketime upstream to improve the documentation on this, which was quickly
accepted, and also disabled this feature in reprotest's own usage of faketime.
buildinfo.debian.net development
There was further work on buildinfo.debian.net code. Chris Lamb added support
for buildinfo format 0.2 and made rejection notices clearer; and Emanuel
Bronshtein fixed some links to use HTTPS.
Misc.
This week's edition was written by Ximin Luo and reviewed by a bunch
of Reproducible Builds folks on IRC and via email.
Previously: v4.8.
Here are a bunch of security things I m excited about in the newly released Linux v4.9:
Latent Entropy GCC plugin
Building on her earlier work to bring GCC plugin support to the Linux kernel, Emese Revfy ported PaX s Latent Entropy GCC plugin to upstream. This plugin is significantly more complex than the others that have already been ported, and performs extensive instrumentation of functions marked with __latent_entropy. These functions have their branches and loops adjusted to mix random values (selected at build time) into a global entropy gathering variable. Since the branch and loop ordering is very specific to boot conditions, CPU quirks, memory layout, etc, this provides some additional uncertainty to the kernel s entropy pool. Since the entropy actually gathered is hard to measure, no entropy is credited , but rather used to mix the existing pool further. Probably the best place to enable this plugin is on small devices without other strong sources of entropy.
vmapped kernel stack and thread_info relocation on x86
Normally, kernel stacks are mapped together in memory. This meant that attackers could use forms of stack exhaustion (or stack buffer overflows) to reach past the end of a stack and start writing over another process s stack. This is bad, and one way to stop it is to provide guard pages between stacks, which is provided by vmalloced memory. Andy Lutomirski did a bunch of work to move to vmapped kernel stack via CONFIG_VMAP_STACK on x86_64. Now when writing past the end of the stack, the kernel will immediately fault instead of just continuing to blindly write.
Related to this, the kernel was storing thread_info (which contained sensitive values like addr_limit) at the bottom of the kernel stack, which was an easy target for attackers to hit. Between a combination of explicitly moving targets out of thread_info, removing needless fields, and entirely moving thread_info off the stack, Andy Lutomirski and Linus Torvalds created CONFIG_THREAD_INFO_IN_TASK for x86.
CONFIG_DEBUG_RODATA mandatory on arm64
As recently done for x86, Mark Rutland made CONFIG_DEBUG_RODATA mandatory on arm64. This feature controls whether the kernel enforces proper memory protections on its own memory regions (code memory is executable and read-only, read-only data is actually read-only and non-executable, and writable data is non-executable). This protection is a fundamental security primitive for kernel self-protection, so there s no reason to make the protection optional.
random_page() cleanup
Cleaning up the code around the userspace ASLR implementations makes them easier to reason about. This has been happening for things like the recent consolidation on arch_mmap_rnd() for ET_DYN and during the addition of the entropy sysctl. Both uncovered some awkward uses of get_random_int() (or similar) in and around arch_mmap_rnd() (which is used for mmap (and therefore shared library) and PIE ASLR), as well as in randomize_stack_top() (which is used for stack ASLR). Jason Cooper cleaned things up further by doing away with randomize_range() entirely and replacing it with the saner random_page(), making the per-architecture arch_randomize_brk() (responsible for brk ASLR) much easier to understand.
That s it for now! Let me know if there are other fun things to call attention to in v4.9.
There was a Reproducible Builds hackathon in Boston with contributions from Dafydd, Valerie, Clint, Harlen, Anders, Robbie and Ben. (See the "Bugs filed" section below for the results).
Reviews of unreproducible packages
15 package reviews have been added, 4 have been updated and 26 have been removed in this week,
adding to our knowledge about identified issues.
2 issue types have been added:
Is is available now in Debian, Archlinux and on PyPI.
strip-nondeterminism development
At the Reproducible Builds Boston hackathon Anders Kaseorg filed #846895 treat .par files as Zip archives, including a patch which was merged into master.
reprotest development
reprotest 0.4 was uploaded to unstable by Ximin Luo:
Group all "done" and all "open" usertagged bugs together in the bugs graphs and move the "done bugs" from the bottom of these gaps.
Update list of packages installed on .debian.org machines.
Made the maintenance jobs run every 2h instead of 3h.
Various bug fixes and minor improvements.
After thorough review by Mattia, some patches by Valerie were merged in preparation of the switch from sqlite to Postgresql, most notably a conversion to the sqlalchemy expression language.
Holger gave a talk at Profitbricks about how Debian is using 168 cores, 503 GB RAM and 5 TB storage to make jenkins.debian.net and tests.reproducible-builds.org run. Many thanks to Profitbricks for supporting jenkins.debian.net since August 2012!
Holger created a Jenkins job to build reprotest from git master branch.
Finally, the Jenkins Naginator plugin was installed to retry git cloning in case of Alioth/network failures, this will benefit all jobs using Git on jenkins.debian.net.
Misc.
This week's edition was written by Chris Lamb, Valerie Young, Vagrant Cascadian, Holger Levsen and reviewed by a bunch of Reproducible Builds folks on IRC.
Previously: v4.5. The v4.6 Linux kernel release included a bunch of stuff, with much more of it under the KSPP umbrella.
seccomp support for parisc
Helge Deller added seccomp support for parisc, which including plumbing support for PTRACE_GETREGSET to get the self-tests working.
x86 32-bit mmap ASLR vs unlimited stack fixed
Hector Marco-Gisbert removed a long-standing limitation to mmap ASLR on 32-bit x86, where setting an unlimited stack (e.g. ulimit -s unlimited ) would turn off mmap ASLR (which provided a way to bypass ASLR when executing setuid processes). Given that ASLR entropy can now be controlled directly (see the v4.5 post), and that the cases where this created an actual problem are very rare, means that if a system sees collisions between unlimited stack and mmap ASLR, they can just adjust the 32-bit ASLR entropy instead.
x86 execute-only memory
Dave Hansen added Protection Key support for future x86 CPUs and, as part of this, implemented support for execute only memory in user-space. On pkeys-supporting CPUs, using mmap(..., PROT_EXEC) (i.e. without PROT_READ) will mean that the memory can be executed but cannot be read (or written). This provides some mitigation against automated ROP gadget finding where an executable is read out of memory to find places that can be used to build a malicious execution path. Using this will require changing some linker behavior (to avoid putting data in executable areas), but seems to otherwise Just Work. I m looking forward to either emulated QEmu support or access to one of these fancy CPUs.
CONFIG_DEBUG_RODATA enabled by default on arm and arm64, and mandatory on x86
Ard Biesheuvel (arm64) and I (arm) made the poorly-named CONFIG_DEBUG_RODATA enabled by default. This feature controls whether the kernel enforces proper memory protections on its own memory regions (code memory is executable and read-only, read-only data is actually read-only and non-executable, and writable data is non-executable). This protection is a fundamental security primitive for kernel self-protection, so making it on-by-default is required to start any kind of attack surface reduction within the kernel.
On x86 CONFIG_DEBUG_RODATA was already enabled by default, but, at Ingo Molnar s suggestion, I made it mandatory: CONFIG_DEBUG_RODATA cannot be turned off on x86. I expect we ll get there with arm and arm64 too, but the protection is still somewhat new on these architectures, so it s reasonable to continue to leave an out for developers that find themselves tripping over it.
arm64 KASLR text base offset
Ard Biesheuvel reworked a ton of arm64 infrastructure to support kernel relocation and, building on that, Kernel Address Space Layout Randomization of the kernel text base offset (and module base offset). As with x86 text base KASLR, this is a probabilistic defense that raises the bar for kernel attacks where finding the KASLR offset must be added to the chain of exploits used for a successful attack. One big difference from x86 is that the entropy for the KASLR must come either from Device Tree (in the /chosen/kaslr-seed property) or from UEFI (via EFI_RNG_PROTOCOL), so if you re building arm64 devices, make sure you have a strong source of early-boot entropy that you can expose through your boot-firmware or boot-loader.
zero-poison after free
Laura Abbott reworked a bunch of the kernel memory management debugging code to add zeroing of freed memory, similar to PaX/Grsecurity s PAX_MEMORY_SANITIZE feature. This feature means that memory is cleared at free, wiping any sensitive data so it doesn t have an opportunity to leak in various ways (e.g. accidentally uninitialized structures or padding), and that certain types of use-after-free flaws cannot be exploited since the memory has been wiped. To take things even a step further, the poisoning can be verified at allocation time to make sure that nothing wrote to it between free and allocation (called sanity checking ), which can catch another small subset of flaws.
To understand the pieces of this, it s worth describing that the kernel s higher level allocator, the page allocator (e.g. __get_free_pages()) is used by the finer-grained slab allocator (e.g. kmem_cache_alloc(), kmalloc()). Poisoning is handled separately in both allocators. The zero-poisoning happens at the page allocator level. Since the slab allocators tend to do their own allocation/freeing, their poisoning happens separately (since on slab free nothing has been freed up to the page allocator).
Only limited performance tuning has been done, so the penalty is rather high at the moment, at about 9% when doing a kernel build workload. Future work will include some exclusion of frequently-freed caches (similar to PAX_MEMORY_SANITIZE), and making the options entirely CONFIG controlled (right now both CONFIGs are needed to build in the code, and a kernel command line is needed to activate it). Performing the sanity checking (mentioned above) adds another roughly 3% penalty. In the general case (and once the performance of the poisoning is improved), the security value of the sanity checking isn t worth the performance trade-off.
Tests for the features can be found in lkdtm as READ_AFTER_FREE and READ_BUDDY_AFTER_FREE. If you re feeling especially paranoid and have enabled sanity-checking, WRITE_AFTER_FREE and WRITE_BUDDY_AFTER_FREE can test these as well.
To perform zero-poisoning of page allocations and (currently non-zero) poisoning of slab allocations, build with:
and enable the page allocator poisoning and slab allocator poisoning at boot with this on the kernel command line:
page_poison=on slub_debug=P
To add sanity-checking, change PAGE_POISONING_NO_SANITY=n, and add F to slub_debug as slub_debug=PF .
read-only after init
I added the infrastructure to support making certain kernel memory read-only after kernel initialization (inspired by a small part of PaX/Grsecurity s KERNEXEC functionality). The goal is to continue to reduce the attack surface within the kernel by making even more of the memory, especially function pointer tables, read-only (which depends on CONFIG_DEBUG_RODATA above).
Function pointer tables (and similar structures) are frequently targeted by attackers when redirecting execution. While many are already declared const in the kernel source code, making them read-only (and therefore unavailable to attackers) for their entire lifetime, there is a class of variables that get initialized during kernel (and module) start-up (i.e. written to during functions that are marked __init ) and then never (intentionally) written to again. Some examples are things like the VDSO, vector tables, arch-specific callbacks, etc.
As it turns out, most architectures with kernel memory protection already delay making their data read-only until after __init (see mark_rodata_ro()), so it s trivial to declare a new data section ( .data..ro_after_init ) and add it to the existing read-only data section ( .rodata ). Kernel structures can be annotated with the new section (via the __ro_after_init macro), and they ll become read-only once boot has finished.
The next step for attack surface reduction infrastructure will be to create a kernel memory region that is passively read-only, but can be made temporarily writable (by a single un-preemptable CPU), for storing sensitive structures that are written to only very rarely. Once this is done, much more of the kernel s attack surface can be made read-only for the majority of its lifetime.
As people identify places where __ro_after_init can be used, we can grow the protection. A good place to start is to look through the PaX/Grsecurity patch to find uses of __read_only on variables that are only written to during __init functions. The rest are places that will need the temporarily-writable infrastructure (PaX/Grsecurity uses pax_open_kernel()/pax_close_kernel() for these).
That s it for v4.6, next up will be v4.7!
The Background Story
A year ago, or so, I took some time to search the internet for Free Software that can be used for controlling model railways via a computer. I was happy to find Rocrail [1] being one of only a few applications available on the market. And even more, I was very happy when I saw that it had been licensed under a Free Software license: GPL-3(+).
A month ago, or so, I collected my old M rklin (Digital) stuff from my parents' place and started looking into it again after +15 years, together with my little son.
Some weeks ago, I remembered Rocrail and thought... Hey, this software was GPLed code and absolutely suitable for uploading to Debian and/or Ubuntu. I searched for the Rocrail source code and figured out that it got hidden from the web some time in 2015 and that the license obviously has been changed to some non-free license (I could not figure out what license, though).
This made me very sad! I thought I had found a piece of software that might be interesting for testing with my model railway. Whenever I stumble over some nice piece of Free Software that I plan to use (or even only play with), I upload this to Debian as one of the first steps. However, I highly attempt to stay away from non-free sofware, so Rocrail has become a no-option for me back in 2015.
I should have moved on from here on...
Instead...
Proactively, I signed up with the Rocrail forum and asked the author(s) if they see any chance of re-licensing the Rocrail code under GPL (or any other FLOSS license) again [2]? When I encounter situations like this, I normally offer my expertise and help with such licensing stuff for free. My impression until here already was that something strange must have happened in the past, so that software developers choose GPL and later on stepped back from that decision and from then on have been hiding the source code from the web entirely.
Going deeper...
The Rocrail project's wiki states that anyone can request GitBlit access via the forum and obtain the source code via Git for local build purposes only. Nice! So, I asked for access to the project's Git repository, which I had been granted. Thanks for that.
Trivial Source Code Investigation...
So far so good. I investigated the source code (well, only the license meta stuff shipped with the source code...) and found that the main COPYING files (found at various locations in the source tree, containing a full version of the GPL-3 license) had been replaced by this text:
Copyright (c) 2002 Robert Jan Versluis, Rocrail.net
All rights reserved.
Commercial usage needs permission.
Getting in touch again, still being really interested and wanting to help...
As I consider such a non-license as really dangerous when distributing any sort of software, be it Free or non-free Software, I posted the below text on the Rocrail forum:
Hi Rob,
I just stumbled over this post [3] [link reference adapted for this
blog post), which probably is the one you have referred to above.
It seems that Rocrail contains features that require a key or such
for permanent activation. Basically, this is allowed and possible
even with the GPL-3+ (although Free Software activists will not
appreciate that). As the GPL states that people can share the source
code, programmers can easily deactivate license key checks (and
such) in the code and re-distribute that patchset as they like.
Furthermore, the current COPYING file is really non-protective at
all. It does not really protect you as copyright holder of the
code. Meaning, if people crash their trains with your software, you
could actually be legally prosecuted for that. In theory. Or in the
U.S. ( ;-) ). Main reason for having a long long license text is to
protect you as the author in case your software causes t trouble to
other people. You do not have any warranty disclaimer in your COPYING
file or elsewhere. Really not a good idea.
In that referenced post above, someone also writes about the nuisance
of license discussions in this forum. I have seen various cases
where people produced software and did not really care for
licensing. Some ended with a letter from a lawyer, some with some BIG
company using their code under their copyright holdership and their
own commercial licensing scheme. This is not paranoia, this is what
happens in the Free Software world from time to time.
A model that might be much more appropriate (and more protective to
you as the author), maybe, is a dual release scheme for the code. A
possible approach could be to split Rocrail into two editions:
Community Edition and Professional/Commercial Edition. The Community
Edition must be licensed in a way that it allows re-using the code
in a closed-source, non-free version of Rocrail (e.g. MIT/Expat
License or Apache2.0 License). Thus, the code base belonging to the
community edition would be licensed, say..., as Apache-2.0 and for
the extra features in the Commercial Edition, you may use any
non-free license you want (but please not that COPYING file you have
now, it really does not protect your copyright holdership).
The reason for releasing (a reduced set of features of a) software as
Free Software is to extend the user base. The honey jar effect, as
practise by many huge FLOSS projects (e.g. Owncloud, GitLab, etc.).
If people could install Rocrail from the Debian / Ubuntu archives
directly, I am sure that the user base of Rocrail will increase.
There may also be developers popping up showing an interest in
Rocrail (e.g. like me). However, I know many FLOSS developers (e.g.
like me) that won't waste their free time on working for a non-free
piece of software (without being paid).
If you follow (or want to follow) a business model with Rocrail, then
keep some interesting features in the Commercial Edition and don't
ship that source code. People with deep interest may opt for that.
Furthermore, another option could be dual licensing the code. As the
copyright holder of Rocrail you are free to juggle with licenses and
apply any license to a release you want. For example, this can be
interesing for a free-again Rocrail being shipped via Apple's iStore.
Last but not least, as you ship the complete source code with all
previous changes as a Git project to those who request GitBlit
access, it is possible to obtain all earlier versions of Rocrail. In
the mail I received with my GitBlit credentials, there was some text
that prohibits publishing the code. Fine. But: (in theory) it is
not forbidden to share the code with a friend, for local usage. This
friend finds the COPYING file, frowns and rewinds back to 2015 where
the license was still GPL-3+. GPL-3+ code can be shared with anyone
and also published, so this friend could upload the 2015-version of
Rocrail to Github or such and start to work on a free fork. You also
may not want this.
Thanks for working on this piece of software! It is highly
interesing, and I am still sad, that it does not come with a free
license anymore. I won't continue this discussion and move on, unless
you are interested in any of the above information and ask for more
expertise. Ping me here or directly via mail, if needed. If the
expertise leads to parts of Rocrail becoming Free Software again, the
expertise is offered free of charge ;-).
light+love
Mike
Wow, the first time I got moderated somewhere... What an experience!
This experience now was really new. My post got immediately removed from the forum by the main author of Rocrail (with the forum's moderator's hat on). The new experience was: I got really angry when I discovererd having been moderated. Wow! Really a powerful emotion. No harassment in my words, no secrets disclosed, and still... my free speech got suppressed by someone. That feels intense! And it only occurred in the virtual realm, not face to face. Wow!!! I did not expect such intensity...
The reason for wiping my post without any other communication was given as below and quite a statement to frown upon (this post has also been "moderately" removed from the forum thread [2] a bit later today):
Mike,
I think its not a good idea to point out a way to get the sources back to the GPL periode.
Therefore I deleted your posting.
(The phpBB forum software also allows moderators to edit posts, so the critical passage could have been removed instead, but immediately wiping the full message, well...). Also, just wiping my post and not replying otherwise with some apology to suppress my words, really is a no-go. And the reason for wiping the rest of the text... Any Git user can easily figure out how to get a FLOSS version of Rocrail and continue to work on that from then on. Really.
Now the political part of this blog post...
Fortunately, I still live in an area of the world where the right of free speech is still present. I found out: I really don't like being moderated!!! Esp. if what I share / propose is really noooo secret at all. Anyone who knows how to use Git can come to the same conclusion as I have come to this morning.
[Off-topic, not at all related to Rocrail: The last votes here in Germany indicate that some really stupid folks here yearn for another this time highly idiotic wind of change, where free speech may end up as a precious good.]
To other (Debian) Package Maintainers and Railroad Enthusiasts...
With this blog post I probably close the last option for Rocrail going FLOSS again. Personally, I think that gate was already closed before I got in touch.
Now really moving on...
Probably the best approach for my new train conductor hobby (as already recommended by the woman at my side some weeks back) is to leave the laptop lid closed when switching on the train control units. I should have listened to her much earlier.
I have finally removed the Rocrail source code from my computer again without building and testing the application. I neither have shared the source code with anyone. Neither have I shared the Git URL with anyone. I really think that FLOSS enthusiasts should stay away from this software for now. For my part, I have lost my interest in this completely...
References
Proposed a change to django-enumfield (a custom field for type-safe constants) to ensure passing a string type to Enum.get returned None on error to match the documentation. (#36).
Fixed an issue in the Mopidy music player's podcast extension where the testsuite was failing tests in extreme timezones. (#40).
Proposed changes to make various upstream's reproducible:
cookiecutter, a project template generator, removing nondeterministic keyword arguments from appearing in the documentation. (#800).
pyicu, a Python wraper for the IBM Unicode library. (#27).
Integrated a number of issues raised by @piotr1212 to python-fadvise, my Python interface to posix_fadvise(2), where the API was not being applied to open file descriptors (#1) and moving the .so to a module directory (#2).
Various improvements to try.diffoscope.org, a hosted version of the diffoscope in-depth and content-aware diff utility, including introducing an HTTP API (#21), updating the SSL certificate and correcting a logic issue where errors in diffoscope itself were not being detected correctly (b0ff49). Continued thanks to Bytemark for sponsoring the hardware.
Fixed a bug in django-slack, my library to easily post messages to the Slack group-messaging utility, correcting an EncodeError exception under Python 3 (#53) and updated the minimum required version of Django to 1.7 (#54).
Various updates to tickle-me-email, my Getting Things Done-inspired email toolbox, to also match / in IMAP's LIST separators (#6) and to encode the folder list as UTF-7 (#7). Thanks to @resiak.
Clarified the documentation for travis.debian.net my hosted script to easily test and build Debian packages on the Travis CI continuous integration platform regarding how to integrate with Github (#20).
Reproducible builds
Whilst anyone can inspect the source code of free software for malicious flaws, most Linux distributions provide binary (or "compiled") packages to end users.
The motivation behind the Reproducible Builds effort is to allow verification that no flaws have been introduced either maliciously and accidentally during this compilation process by promising identical binary packages are always generated from a given source.
Toolchain issues
I submitted the following patches to fix reproducibility-related toolchain issues:
My work in the Reproducible Builds project was also covered in our weekly reports. (#67, #68, #69, #70).
Diffoscope
diffoscope is our "diff on steroids" that will not only recursively unpack archives but will transform binary formats into human-readable forms in order to compare them:
Improve the top-level navigation so that we can always get back to "home" of a package.
Give expandable elements cursor: pointer CSS styling to highlight they are clickable.
Drop various trailing underlined whitespaces after links.
Explicitly log that build was successful or not.
Various code-quality improvements, including prefering str.format over concatentation.
Miscellaneous updates to our filter-packages internal tool:
Add --random=N and --url options.
Add support for --show=comments.
Correct ordering so that --show-version runs after --filter-ftbfs.
Rename --show-ftbfs to --filter-ftbfs and --show-version to --show=version.
Created a proof-of-concept reproducible-utils package to contain commonly-used snippets aimed at developers wishing to make their packages reproducible.
Authored the patch & issued DLA 596-1 for extplorer, a web-based file manager, fixing an archive traversal exploit.
Issued DLA 598-1 for suckless-tools, fixing a segmentation fault in the slock screen locking tool.
Issued DLA 599-1 for cracklib2, a pro-active password checker library, fixing a stack-based buffer overflow when parsing large GECOS fields.
Improved the find-work internal tool adding optional colour highlighting and migrating it to Python 3.
Wrote an lts-missing-uploads tool to find mistakes where there was no correponding package in the archive after an announcement.
Added optional colour highlighting to the lts-cve-triage tool.
Uploads
redis 2:3.2.3-1 New upstream release, move to the DEP-5 debian/copyright format, ensure that we are running as root in LSB initscripts and add a README.Source regarding our local copies of redis.conf and sentinel.conf.
4.2.5-1 Take over package maintenance, completely overhauling the packaging with a new upstream version, move to virtual-mysql-server to support MariaDB, updating package names of dependencies and fix the outdated Apache configuration.
The second pre-conference day was dedicated to books and beers, with a visit to an exquisite print studio, and a beer tasting session at one of the craft breweries in Canada. In addition we could grab a view into the Canadian lifestyle by visiting Pavneet s beautiful house in the countryside, as well as enjoying traditional style pastries from a bakery.
In short, a perfect combination for us typography and beer savvy freaks!
This morning we had somehow an early start from the hotel. Soon the bus left downtown Toronto and entered countryside Ontario, large landscapes filled with huge (for my Japanese feeling) estates and houses, separated by fields, forests and wild landscape. Very beautiful and inviting to live there. On our way to the printing workshop we stopped at Pavneet s house for a very short visit of the exterior, which includes mathematics in the bricking. According to Pavneet, his kids hate to see math on the wall I would be proud to have it.
A bit further on we entered into Erin, where the Porcupine s Quill is located. A small building along the street, one could easily oversee that rare jewel! In addition considering that according to the owners, Google Maps has a bad error which would lead you to a completely different location. This printing workshop, led by Tim and Elke Inkster, is producing books in a traditional style using an old Heidelberg Offset printing machine.
Elke introduced us to the sewing of folded signatures together with a lovely old sewing machine. It was the first time I actually saw one in action.
Tim, the head master of the printing shop, first entertained us with stories about Chinese publishers visiting them in the old cold-war times, before diving into explanations of the actual machines around, like the Heidelberg offset printing machine.
In the back of the basement of the little studio there is also a huge folding machine, which cuts up the big signatures of 16 pages and folds them into bundles. An impressive example of tricky engineering.
Due to the small size of the printing studio, our groups were actually split into two groups, and while the other group got its guided tour, we grabbed coffee and traditional cookies and pastries from the nearby Holtom s bakery. Loads of nice pastries with various filling, my favorite being the slightly salty cherry pie, and above all the rhubarb-raspberry pie.
To my absolute astonishment I also found there a Viennese Kaisersemmel , called Kaiser bun here, but keeping the shape and the idea (but unfortunately not the crispy cracky quality of the original in Vienna). Of course I got two of them, together with a nice jam from the region, and enjoyed these Viennese breakfast the next day morning.
Leaving the Quill we headed for a lunch in a nice pizzeria (I got Pizza Toscana) which also served excellent local beer how would I like to have something like this over in Japan! Our last stop on this excursion was Stone Hammer Brewery, ne of the most famous craft breweries in Canada.
Although they wont win a prize for typography (besides one page of a coaster there that carried a nice pun), their beers are exquisite. We got five different beers to taste, plus extensive explanations on brewing methods and differences. Now I finally understand why most of the new craft breweries in Japan are making Ales: Ales don t need a long process and are ready for sale in rather short time, compared to e.g. lagers.)
Also at the Stone Hammer Brewery I spotted this very nice poster on the wall of the toilet. And I cannot agree more, everything can easily be discussed over a good beer it calms down aversions, makes even the worst enemies friends, and is healthy for both the mind and body.
Filled with excellent beer, some of us (notably an unnamed US TeXnician and politician), stacked up on beers to carry home. I was very tempted to get a huge batch, but putting cans into an airplane seems to be not the optimal idea. Since we are talking cans, I was surprised to hear that many craft beer brewers nowadays prefer cans due to their better protection of the beer from light and oxygen, both killers of good beer.
Before leaving we took a last look at the Periodic Table of Beer Types, which left me in awe about how much I don t know and I probably never will know. In particular, I heard the first time of a Vienna style beer Vienna is not really famous for beer, better to say, it is infamous. So maybe this is a different Vienna than my home town that is meant here.
Another two hour bus ride brought us back to Toronto, where we met with other participants at the reception in a restaurant of Mediterranean cuisine, where I could enjoy for the first time in years a good Tahina and Humus.
All around another excellent day, now I only would like to have two days of holidays, guess I need to relax in the lectures starting from tomorrow.
Summer vacations have been getting tougher in recent years. Airlines cut into your precious vacation time with their online check-in procedures and a dozen reminder messages, there is growing concern about airport security and Brexit has already put one large travel firm into liquidation leaving holidaymakers in limbo.
If that wasn't all bad enough, now there is a new threat: while you are relaxing in the sun, scammers fool your phone company into issuing a replacement SIM card or transferring your mobile number to a new provider and then proceed to use it to take over all your email, social media, Paypal and bank accounts. The same scam has been appearing around the globe, from Britain to Australia and everywhere in between. Many of these scams were predicted in my earlier blog SMS logins: an illusion of security (April 2014) but they are only starting to get publicity now as more aspects of our lives are at risk, scammers are ramping up their exploits and phone companies are floundering under the onslaught.
With the vast majority of Internet users struggling to keep their passwords out of the wrong hands, many organizations have started offering their customers the option of receiving two-factor authentication codes on their mobile phone during login. Rather than making people safer, this has simply given scammers an incentive to seize control of telephones, usually by tricking the phone company to issue a replacement SIM or port the number. It also provides a fresh incentive for criminals to steal phones while cybercriminals have been embedding code into many "free" apps to surreptitiously re-route the text messages and gather other data they need for an identity theft sting.
Sadly, telephone networks were never designed for secure transactions. Telecoms experts have made this clear numerous times. Some of the largest scams in the history of financial services exploited phone verification protocols as the weakest link in the chain, including a $150 million heist reminiscent of Ocean's 11.
For phone companies, SMS messaging came as a side-effect of digital communications for mobile handsets. It is less than one percent of their business. SMS authentication is less than one percent of that. Phone companies lose little or nothing when SMS messages are hijacked so there is little incentive for them to secure it. Nonetheless, like insects riding on an elephant, numerous companies have popped up with a business model that involves linking websites to the wholesale telephone network and dressing it up as a "security" solution. These companies are able to make eye-watering profits by "purchasing" text messages for $0.01 and selling them for $0.02 (one hundred percent gross profit), but they also have nothing to lose when SIM cards are hijacked and therefore minimal incentive to take any responsibility.
Companies like Google, Facebook and Twitter have thrown more fuel on the fire by encouraging and sometimes even demanding users provide mobile phone numbers to "prove they are human" or "protect" their accounts. Through these antics, these high profile companies have given a vast percentage of the population a false sense of confidence in codes delivered by mobile phone, yet the real motivation for these companies does not appear to be security at all: they have worked out that the mobile phone number is the holy grail in cross-referencing vast databases of users and customers from different sources for all sorts of creepy purposes. As most of their services don't involve any financial activity, they have little to lose if accounts are compromised and everything to gain by accurately gathering mobile phone numbers from as many users as possible.
Can you escape your mobile phone while on vacation?
Just how hard is it to get a replacement SIM card or transfer/port a user's phone number while they are on vacation? Many phone companies will accept instructions through a web form or a phone call. Scammers need little more than a user's full name, home address and date of birth: vast lists of these private details are circulating on the black market, sourced from social media, data breaches (99% of which are never detected or made public), marketing companies and even the web sites that encourage your friends to send you free online birthday cards.
Every time a company has asked me to use mobile phone authentication so far, I've opted out and I'll continue to do so. Even if somebody does hijack my phone account while I'm on vacation, the consequences for me are minimal as it will not give them access to any other account or service, can you and your family members say the same thing?
What can be done?
Opt-out of mobile phone authentication schemes.
Never give the mobile phone number to web sites unless there is a real and pressing need for them to call you.
Tell firms you don't have a mobile phone or that you share your phone with your family and can't use it for private authentication.
If you need to use two-factor authentication, only use technical solutions such as smart cards or security tokens that have been engineered exclusively for computer security. Leave them in a locked drawer or safe while on vacation. Be wary of anybody who insists on SMS and doesn't offer these other options.
Rather than seeking to "protect" accounts, simply close some or all social media accounts to reduce your exposure and eliminate the effort of keeping them "secure" and updating "privacy" settings.
If your bank provides a relationship manager or other personal contact, this
can also provide a higher level of security as they get to know you.
As some of the world knows full well by now, I've been noodling with Go
for a few years, working through its pros, its cons, and thinking a lot
about how humans use code to express thoughts and ideas. Go's got a lot of
neat use cases, suited to particular problems, and used in the right place,
you can see some clear massive wins.
I've started writing Debian tooling in Go, because it's a pretty natural fit.
Go's fairly tight, and overhead shouldn't be taken up by your operating system.
After a while, I wound up hitting the usual blockers, and started to build up
abstractions. They became pretty darn useful, so, this blog post is announcing
(a still incomplete, year old and perhaps API changing) Debian package for Go.
The Go importable name is pault.ag/go/debian. This contains a lot of utilities
for dealing with Debian packages, and will become an edited down "toolbelt"
for working with or on Debian packages.
Module Overview
Currently, the package contains 4 major sub packages. They're a changelog
parser, a control file parser, deb file format parser, dependency parser
and a version parser. Together, these are a set of powerful building blocks
which can be used together to create higher order systems with reliable
understandings of the world.
changelog
The first (and perhaps most incomplete and least tested) is a changelog file
parser.. This provides the
programmer with the ability to pull out the suite being targeted in the
changelog, when each upload was, and the version for each. For example, let's
look at how we can pull when all the uploads of Docker to sid took place:
funcmain()resp,err:=http.Get("http://metadata.ftp-master.debian.org/changelogs/main/d/docker.io/unstable_changelog")iferr!=nilpanic(err)allEntries,err:=changelog.Parse(resp.Body)iferr!=nilpanic(err)for_,entry:=rangeallEntriesfmt.Printf("Version %s was uploaded on %s\n",entry.Version,entry.When)
The output of which looks like:
Version 1.8.3~ds1-2 was uploaded on 2015-11-04 00:09:02 -0800 -0800
Version 1.8.3~ds1-1 was uploaded on 2015-10-29 19:40:51 -0700 -0700
Version 1.8.2~ds1-2 was uploaded on 2015-10-29 07:23:10 -0700 -0700
Version 1.8.2~ds1-1 was uploaded on 2015-10-28 14:21:00 -0700 -0700
Version 1.7.1~dfsg1-1 was uploaded on 2015-08-26 10:13:48 -0700 -0700
Version 1.6.2~dfsg1-2 was uploaded on 2015-07-01 07:45:19 -0600 -0600
Version 1.6.2~dfsg1-1 was uploaded on 2015-05-21 00:47:43 -0600 -0600
Version 1.6.1+dfsg1-2 was uploaded on 2015-05-10 13:02:54 -0400 EDT
Version 1.6.1+dfsg1-1 was uploaded on 2015-05-08 17:57:10 -0600 -0600
Version 1.6.0+dfsg1-1 was uploaded on 2015-05-05 15:10:49 -0600 -0600
Version 1.6.0+dfsg1-1~exp1 was uploaded on 2015-04-16 18:00:21 -0600 -0600
Version 1.6.0~rc7~dfsg1-1~exp1 was uploaded on 2015-04-15 19:35:46 -0600 -0600
Version 1.6.0~rc4~dfsg1-1 was uploaded on 2015-04-06 17:11:33 -0600 -0600
Version 1.5.0~dfsg1-1 was uploaded on 2015-03-10 22:58:49 -0600 -0600
Version 1.3.3~dfsg1-2 was uploaded on 2015-01-03 00:11:47 -0700 -0700
Version 1.3.3~dfsg1-1 was uploaded on 2014-12-18 21:54:12 -0700 -0700
Version 1.3.2~dfsg1-1 was uploaded on 2014-11-24 19:14:28 -0500 EST
Version 1.3.1~dfsg1-2 was uploaded on 2014-11-07 13:11:34 -0700 -0700
Version 1.3.1~dfsg1-1 was uploaded on 2014-11-03 08:26:29 -0700 -0700
Version 1.3.0~dfsg1-1 was uploaded on 2014-10-17 00:56:07 -0600 -0600
Version 1.2.0~dfsg1-2 was uploaded on 2014-10-09 00:08:11 +0000 +0000
Version 1.2.0~dfsg1-1 was uploaded on 2014-09-13 11:43:17 -0600 -0600
Version 1.0.0~dfsg1-1 was uploaded on 2014-06-13 21:04:53 -0400 EDT
Version 0.11.1~dfsg1-1 was uploaded on 2014-05-09 17:30:45 -0400 EDT
Version 0.9.1~dfsg1-2 was uploaded on 2014-04-08 23:19:08 -0400 EDT
Version 0.9.1~dfsg1-1 was uploaded on 2014-04-03 21:38:30 -0400 EDT
Version 0.9.0+dfsg1-1 was uploaded on 2014-03-11 22:24:31 -0400 EDT
Version 0.8.1+dfsg1-1 was uploaded on 2014-02-25 20:56:31 -0500 EST
Version 0.8.0+dfsg1-2 was uploaded on 2014-02-15 17:51:58 -0500 EST
Version 0.8.0+dfsg1-1 was uploaded on 2014-02-10 20:41:10 -0500 EST
Version 0.7.6+dfsg1-1 was uploaded on 2014-01-22 22:50:47 -0500 EST
Version 0.7.1+dfsg1-1 was uploaded on 2014-01-15 20:22:34 -0500 EST
Version 0.6.7+dfsg1-3 was uploaded on 2014-01-09 20:10:20 -0500 EST
Version 0.6.7+dfsg1-2 was uploaded on 2014-01-08 19:14:02 -0500 EST
Version 0.6.7+dfsg1-1 was uploaded on 2014-01-07 21:06:10 -0500 EST
control
Next is one of the most complex, and one of the oldest parts of go-debian,
which is the control file parser
(otherwise sometimes known as deb822). This module was inspired by the way
that the json module works in Go, allowing for files to be defined in code
with a struct. This tends to be a bit more declarative, but also winds up
putting logic into struct tags, which can be a nasty anti-pattern if used too
much.
The first primitive in this module is the concept of a Paragraph, a struct
containing two values, the order of keys seen, and a map of string to string.
All higher order functions dealing with control files will go through this
type, which is a helpful interchange format to be aware of. All parsing of
meaning from the Control file happens when the Paragraph is unpacked into
a struct using reflection.
The idea behind this strategy that you define your struct, and let the Control
parser handle unpacking the data from the IO into your container, letting you
maintain type safety, since you never have to read and cast, the conversion
will handle this, and return an Unmarshaling error in the event of failure.
Additionally, Structs that define an anonymous member of control.Paragraph
will have the raw Paragraph struct of the underlying file, allowing the
programmer to handle dynamic tags (such as X-Foo), or at least, letting
them survive the round-trip through go.
The default decoder
contains an argument, the ability to verify the input control file using an
OpenPGP keyring, which is exposed to the programmer through the
(*Decoder).Signer() function. If the passed argument is nil, it will not
check the input file signature (at all!), and if it has been passed, any
signed data must be found or an error will fall out of the NewDecoder call.
On the way out, the opposite happens, where the struct is introspected,
turned into a control.Paragraph, and then written out to the io.Writer.
Here's a quick (and VERY dirty) example showing the basics of reading and
writing Debian Control files with go-debian.
packagemainimport("fmt""io""net/http""strings""pault.ag/go/debian/control")typeAllowedPackagestructPackagestringFingerprintstringfunc(a*AllowedPackage)UnmarshalControl(instring)errorin=strings.TrimSpace(in)chunks:=strings.SplitN(in," ",2)iflen(chunks)!=2returnfmt.Errorf("Syntax sucks: '%s'",in)a.Package=chunks[0]a.Fingerprint=chunks[1][1:len(chunks[1])-1]returnniltypeDMUAstructFingerprintstringUidstringAllowedPackages[]AllowedPackage control:"Allow" delim:"," funcmain()resp,err:=http.Get("http://metadata.ftp-master.debian.org/dm.txt")iferr!=nilpanic(err)decoder,err:=control.NewDecoder(resp.Body,nil)iferr!=nilpanic(err)fordmua:=DMUAiferr:=decoder.Decode(&dmua);err!=niliferr==io.EOFbreakpanic(err)fmt.Printf("The DM %s is allowed to upload:\n",dmua.Uid)for_,allowedPackage:=rangedmua.AllowedPackagesfmt.Printf(" %s [granted by %s]\n",allowedPackage.Package,allowedPackage.Fingerprint)
Output (truncated!) looks a bit like:
...
The DM Allison Randal <allison@lohutok.net> is allowed to upload:
parrot [granted by A4F455C3414B10563FCC9244AFA51BD6CDE573CB]
...
The DM Benjamin Barenblat <bbaren@mit.edu> is allowed to upload:
boogie [granted by 3224C4469D7DF8F3D6F41A02BBC756DDBE595F6B]
dafny [granted by 3224C4469D7DF8F3D6F41A02BBC756DDBE595F6B]
transmission-remote-gtk [granted by 3224C4469D7DF8F3D6F41A02BBC756DDBE595F6B]
urweb [granted by 3224C4469D7DF8F3D6F41A02BBC756DDBE595F6B]
...
The DM <aelmahmoudy@sabily.org> is allowed to upload:
covered [granted by 41352A3B4726ACC590940097F0A98A4C4CD6E3D2]
dico [granted by 6ADD5093AC6D1072C9129000B1CCD97290267086]
drawtiming [granted by 41352A3B4726ACC590940097F0A98A4C4CD6E3D2]
fonts-hosny-amiri [granted by BD838A2BAAF9E3408BD9646833BE1A0A8C2ED8FF]
...
...
deb
Next up, we've got the deb module. This contains code to handle reading
Debian 2.0 .deb files. It contains a wrapper that will parse the control
member, and provide the data member through the
archive/tar interface.
Here's an example of how to read a .deb file, access some metadata, and
iterate over the tar archive, and print the filenames of each of the
entries.
dependency
The dependency package provides an interface to parse and compute
dependencies. This package is a bit odd in that, well, there's no other
library that does this. The issue is that there are actually two different
parsers that compute our Dependency lines, one in Perl (as part of dpkg-dev)
and another in C (in dpkg).
To date, this has resulted in me filing
threedifferentbugs.
I also found a broken package in the
archive,
which actually resulted in another bug being (totally accidentally)
already fixed.
I hope to continue to run the archive through my parser in hopes of finding
more bugs! This package is a bit complex, but it basically just returns what
amounts to be an AST
for our Dependency lines. I'm positive there are bugs, so file them!
funcmain()dep,err:=dependency.Parse("foo bar, baz, foobar [amd64] bazfoo [!sparc], fnord:armhf [gnu-linux-sparc]")iferr!=nilpanic(err)anySparc,err:=dependency.ParseArch("sparc")iferr!=nilpanic(err)for_,possi:=rangedep.GetPossibilities(*anySparc)fmt.Printf("%s (%s)\n",possi.Name,possi.Arch)
Gives the output:
foo (<nil>)
baz (<nil>)
fnord (armhf)
version
Right off the bat, I'd like to thank
Michael Stapelberg for letting me graft this
out of dcs and into the go-debian package.
This was nearly entirely his work (with a one or two line function I added
later), and was amazingly helpful to have. Thank you!
This module implements Debian version comparisons and parsing, allowing for
sorting in lists, checking to see if it's native or not, and letting the
programmer to implement smart(er!) logic based on upstream (or Debian)
version numbers.
This module is extremely easy to use and very straightforward, and not worth
writing an example for.
Final thoughts
This is more of a "Yeah, OK, this has been useful enough to me at this point
that I'm going to support this" rather than a "It's stable!" or even
"It's alive!" post. Hopefully folks can report bugs and help iterate on
this module until we have some really clean building blocks to build
solid higher level systems on top of. Being able to have multiple libraries
interoperate by relying on go-debian will be a massive ease.
I'm in need of more documentation, and to finalize some parts of the older
sub package APIs, but I'm hoping to be at a "1.0" real soon now.
There has been some silence on the Gammu release front and it's time to change that. Today all Gammu, python-gammu and Wammu have been released. As you might guess all are bugfix releases.
List of changes for Gammu 1.37.3:
In the ARM world, to which I am still mostly a newcomer (although I've been already playing with ARM machines for over two years, I am a complete newbie compared to my Debian friends who live and breathe that architecture), the most common way to distribute operating systems is to distribute complete, already-installed images. I have ranted in the past on how those images ought to be distributed.
Some time later, I also discussed on my blog on how most of this hardware requires unauditable binary blobs and other non-upstreamed modifications to Linux.
In the meanwhile, I started teaching on the Embedded Linux diploma course in Facultad de Ingenier a, UNAM. It has been quite successful And fun.
Anyway, one of the points we make emphasis on to our students is that the very concept of embedded makes the mere idea of downloading a pre-built, 4GB image, loaded with a (supposedly lightweight, but far fatter than my usual) desktop environment and whatnot an irony.
As part of the "Linux Userspace" and "Boot process" modules, we make a lot of emphasis on how to build a minimal image. And even leaving installed size aside, it all boils down to trust. We teach mainly four different ways of setting up a system:
Using our trusty Debian Installer in the (unfortunately few) devices where it is supported
Installing via Debootstrap, as I did in my CuBox-i tutorial (note that the tutorial is nowadays obsolete. The CuBox-i can boot with Debian Installer!) and just keeping the boot partition (both for u-boot and for the kernel) of the vendor-provided install
Building a barebones system using the great Buildroot set of scripts and hacks
Downloading a full, but minimal, installed image, such as OpenWRT (I have yet to see what's there about its fork, LEDE)
Now... In the past few days, a huge vulnerability / oversight was discovered and made public, supporting my distrust of distribution forms that do not come from, well... The people we already know and trust to do this kind of work!
Most current ARM chips cannot run with the stock, upstream Linux kernel. Then require a set of patches that different vendors pile up to support their basic hardware (remember those systems are almost always systems-on-a-chip (SoC)). Some vendors do take the hard work to try to upstream their changes that is, push the changes they did to the kernel for inclusion in mainstream Linux. This is a very hard task, and many vendors just abandon it.
So, in many cases, we are stuck running with nonstandard kernels, full with huge modifications... And we trust them to do things right. After all, if they are knowledgeable enough to design a SoC, they should do at least decent kernel work, right?
Turns out, it's far from the case. I have a very nice and nifty Banana Pi M3, based on the Allwinner A83T SoC. 2GB RAM, 8 ARM cores... A very nice little system, almost usable as a desktop. But it only boots with their modified 3.4.x kernel.
This kernel has a very ugly flaw: A debugging mode left open, that allows any local user to become root. Even on a mostly-clean Debian system, installed by a chrooted debootstrap:
Why? Oh, well, in this kernel somebody forgot to comment out (or outright remove!) the sunxi-debug.c file, or at the very least, a horrid part of code therein (it's a very small, simple file):
if(!strncmp("rootmydevice",(char*)buf,12))
cred =(struct cred *)__task_cred(current);
cred->uid =0;
cred->gid =0;
cred->suid =0;
cred->euid =0;
cred->euid =0;
cred->egid =0;
cred->fsuid =0;
cred->fsgid =0;
printk("now you are root\n");
Now... Just by looking at this file, many things should be obvious. For example, this is not only dangerous and lazy (it exists so developers can debug by touching a file instead of... typing a password?), but also goes against the kernel coding guidelines the file is not documented nor commented at all. Peeking around other files in the repository, it gets obvious that many files lack from this same basic issue and having this upstreamed will become a titanic task. If their programmers tried to adhere to the guidelines to begin with, integration would be a much easier path. Cutting the wrong corners will just increase the needed amount of work.
Anyway, enough said by me. Some other sources of information:
Commit fixing it on the SinoVoip repository Of course, the fun part will be delivering it to users. If affected machines are effectively running as embedded systems of any sort... good luck with it! :-P
There are surely many other mentions of this. I just had to repeat it for my local echo chamber, and for future reference in class! ;-)
Two Factor authentication and general improvement of my security infrastructure was long on my todo list. Some month ago I finally purchased a Yubikey NEO from Yubico and try to consistently use it as second factor, as well as gpg signing/encrypting device.
I am trying to get the best out of my Yubikey NEO by using as many of its functionality, in particular: Smartcard for my GNuPG keys, OTP similar to Google Authenticator and similar, as well as challenge-response for additional login security, as well as all that over NFC to not keep keys/passwords on my mobile phone.
While there are loads of guides (see the previous article on GnuPG for some of them), many of them are out-of-date for current distributions and GnuPG etc. So I tried to collect all I could find not the least to have a place to look it up in case I forget it again.
The Hardware
The Yubikey NEO is a great peace of hardware. I not even remotely understand how they manage that this little beast can do all these things and still work out without mixing things up. As far as I understand (please correct me) it has three independent circuits of communication:
HID mode working as keyboard and sending keystrokes
CCID mode (smartcard) for PIV / GnuPG / OpenGPG functionality
Yubikey mode setup
There are several modes, and using the ykpersonalize tool (readily available for Windows, Mac, Linux, and in the Debian package yubikey-personalization) one can program the key to work in a variety of modes. I chose to activate all options by passing in -m86 which stand for OTP/U2F/CCID composite device with MODE_FLAG_EJECT.
$ ykpersonalize -m86
Firmware version 3.4.3 Touch level 1792 Unconfigured
The USB mode will be set to: 0x86
Commit? (y/n) [n]: y
$
It is a good idea to unplug and replug the key after this operation.
Yubikey udev rules for user access
To allow users but root to use the Yubikey, additional udev rules are necessary:
which I put into /etc/udev/rules.d/99-yubikeys.rules on Debian. After that another unplug and replug should allow normal user to access the key. This can be checked by calling getfacl on the newly created /dev/hidraw? device.
Using the HID/Challenge-Response mode (slot 2)
If you want to secure your login with an additional second factor, there are several options documented on the Yubico site concerning yubico-pam. Since I cannot be sure to be always online with my laptop, I choose Challenge-Response authentication, and followed one-to-one Yubico s docs Local Authentication Using Challenge Response. Basically it boils down to install libpam-yubico, select mode-challenge-response when asked for configuration. Then one needs to personalizing the key (in particular slot 2) for challenge response with:
Next we need to save the challenge and expected response to the user s directory:
$ mkdir $HOME/.yubico
$ ykpamcfg -2 -v
...
Stored initial challenge and expected response in '/home/norbert/.yubico/challenge-123456'.
$
It might be a good idea to try this out, and if it works, activate it also for root. But be careful no key no login
Challenge: I am currently searching for a method to replace the second factor of they key optionally with a different authentication method, like a very difficult passphrase. This way I could log in even without my key, but in this case would need the complicated passphrase. From my reading of the pam manuals it seems to be possible, and I am planning to use pam_ssh and a specific login key with a complicated passphrase. I will report back when this is done.
YubiOATH (TOTP) Time based One Time Passwords (aka Google Authenticator style)
Without any setup whatsoever this worked out of the box. I use the Yubico Authenticator on my Android phone, and the dedicated application for the Linux desktop to create second factors for all kind of applications. Currently I am using it with Google login, Github, DropbBox, and WordPress (via the Two Factor plugin which can also be tweaked to use the NEO key as USB key via the FIDO U2F).
Challenge: If I start the Yubico Personalization GUI, I see two free slots so where are the TOTPs computed? That also means that I have one slot free and for now I don t know what to do with it
Yubikey OpenGPG applet setup
The Yubikeys support OpenPGP, and the applet is pre-installed (afaik), meaning you can directly configure the key and upload your keys. Here I use gpg2 (2.1) as it seems to better support card operations. To not interfere with the current gpg setup I use a temporary gpg home:
$ mkdir gpgtmp
$ chmod go-rwx gpgtmp
$ gpg2 --homedir gpgtmp --list-keys
gpg: keybox 'gpgtmp/pubring.kbx' created
gpg: gpgtmp/trustdb.gpg: trustdb created
Warning: The YubiKey NEO only supports 2048bit keys. If you want 4096bit keys you need to use one of the newer YubiKey 4, which gives you this option, but does not have support for NFC, and thus no way to interact with an Android (or other) mobile phone.
Check the correct version of the applet
There has been a bug in an older version of the applet, but since 2 years all keys sold should have a correct applet. You can check by:
$ gpg-connect-agent --homedir gpgtmp --hex "scd apdu 00 f1 00 00" /bye"
gpg-connect-agent: no running gpg-agent - starting '/usr/bin/gpg-agent'
gpg-connect-agent: waiting for the agent to come up ... (5s)
gpg-connect-agent: connection to agent established
D[0000] 01 00 10 90 00 .....
OK
Looking at the output one sees D[0000] 01 00 10 which means applet version 1.0.10, which is the first version fixed.
Replace pins of the key
The standard pins are 123456 for the user pin, and 12345678 for the admin pin. These need immediate change!
Warning: When changing the ping the normal pin must be 6 (at least?) digits, and the admin pin 8 (at least?), other gpg2 cannot use the key anymore. No idea why.
$ gpg2 --homedir gpgtmp --card-edit
Reader ...........: 1050:0116:X:0
Application ID ...: D2760001240102000006036457190000
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: 03645719
Name of cardholder: [not set]
Language prefs ...: [not set]
Sex ..............: unspecified
URL of public key : [not set]
Login data .......: [not set]
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]
gpg/card> admin
Admin commands are allowed
gpg/card> passwd
gpg: OpenPGP card no. D2760001240102000006036457190000 detected
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? 3
PIN changed.
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? 1
PIN changed.
1 - change PIN
2 - unblock PIN
3 - change Admin PIN
4 - set the Reset Code
Q - quit
Your selection? q
gpg/card> quit
After this you need to use the new pins for all changes.
Setup basic data
The key can also save some basic data about yourself, like name, sex, language preferences, login name, and url to obtain the public key. As before start gpg2 and then change these infos in the following way>
gpg/card> name
Cardholder's surname: Preining
Cardholder's given name: Norbert
gpg/card> sex
Sex ((M)ale, (F)emale or space): M
gpg/card> lang
Language preferences: de
gpg/card> login
Login data (account name): norbert
gpg/card> url
URL to retrieve public key: https://www.preining.info/preining-norbert.asc
gpg/card> list
Reader ...........: 1050:0116:X:0
Application ID ...: D2760001240102000006036457190000
Version ..........: 2.0
Manufacturer .....: Yubico
Serial number ....: 03645719
Name of cardholder: Norbert Preining
Language prefs ...: de
Sex ..............: male
URL of public key : https://www.preining.info/preining-norbert.asc
Login data .......: norbert
Signature PIN ....: forced
Key attributes ...: rsa2048 rsa2048 rsa2048
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 3 3
Signature counter : 0
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]
General key info..: [none]
gpg/card> quit
Move sub keys to Yubikey
As laid out in the article on GnuPG subkeys, we are having three subkeys for signing, encryption, and authentication. In reality I will practically only use the signing key, but upload all three keys to the card. In the following I expect that you have a setup more or less similar to the one described in the article linked before.
Again, we use GnuPG v2, mostly because it was the version that worked out of the box. In addition, if you are setting up a similar stage like in my GNuPG article with gpg1 keys on the mail server, then you don t want the gpg1 keys being removed.
Basically you must have the Yubikey plugged in and call keytocard after selecting each key in turn (and deselecting it afterwards).
Warning: There is another bug in the GnuPG applet that was fixed in later versions (but not in 1.0.10), namely that not all keys are accepted. This is a bit a pain. I needed to recreate a subkey to obtain a key that can be loaded onto the Yubikey. Unfortunately, Yubico has also stopped/disabled the ability to update applets (although I have to say their documentation is an incredible rubbish with respect to applets and upgrades ).
As before, assume that $MASTERKEY contains the hex id of your master key.
After that your keys are on the Yubikey (and only there!), and GNuPG will require the PIN (user pin) to sign/encrypt documents.
Usage
Many things have been said above, but to sum up when and how I am using the YubiKey now:
Logging into my computer: I need to have the key plugged in, otherwise authentication will not succeed.
GPG activities (signing, encryption): Key needs to be plugged in, GnuPG will ask the User pin.
TOTP (Google, GitHub, WordPress, DropBox login): I use my mobile (Nexus 6p) and the Yubico Authenticator, touch the phone with the Yubikey, and see the TOTPs in the application windows.
OpenKeychain (Android app) integrates with K-9 Mail signing, encryption and decryption is possible on the mobile via NFC (touching the device with the key)
Conclusions
With this setup I am now quite content, but not completely. What I still want to do is full disk encryption where I need the Yubikey to boot and again, with an alternative for a very long passphrase. At the end, adding a second factor to the login is not really optimal, and only protects you against quick hacks. If the laptop is actually stolen, only full disc protection helps. Access to the hardware always guarantees that one has access to everything on the disc.
Another thing I want to do is re-use the GnuPG key on the Yubikey as ssh key for logging into remote systems. That would mean that I get rid of even more keys on my laptop. But this is still in the work
The other open question is what to use the other available slot of the Yubikey for? I thought about some passwords (possible), but I don t feel to happy about having my password issued with the press of a key.
But all in all, I like the setup much more than before and not having any GnuPG key on the laptop is a big plus.
We're excited to announce that Debian has selected 29 interns to work with us
this summer: 4 in Outreachy, and 25 in the Google Summer of Code.
Here is the list of projects and the interns who will work on them:
Android SDK tools in Debian:
The Google Summer of Code and Outreachy programs are possible in Debian thanks
to the effort of Debian developers and contributors that dedicate
part of their free time to mentor students and outreach tasks.
Join us and help extend Debian! You can follow the students weekly reports on the
debian-outreach mailing-list, chat with us on
our IRC channel or on each project's team mailing lists.
Congratulations to all of them!
As some of you may know, I have been working on a small hardware project called
the Beer'o'Meter whose purpose is to allow us to extend Ye Olde Vic's beer
board to indicate the approximate fullness of each cask. For some time now,
we've been operating an electronic beer board at the Vic which you may see
tweeted out from time to time. The pumpotron has become very popular
with the visitors to the pub, especially that it can be viewed online in
a basic textual form.
Of course, as many of you who visit pubs know only too well. That a beer is
"on" is no indication of whether or not you need to get there sharpish to
have a pint, or if you can take your time and have a curry first. As a result,
some of us have noticed a particular beer on, come to the pub after dinner,
and then been very sad that if only we'd come 30 minutes previously, we'd have
had a chance at the very beer we were excited about.
Combine this kind of sadness with a two week break at Christmas, and I started
to develop a Beer'o'Meter to extend the pumpotron with an indication of how
much of a given beer had already been served. Recently my boards came back
from Elecrow along with various bits and bobs, and I have spent some time
today building one up for test purposes.
As always, it's important to start with some prep work to collect all the
necessary components. I like to use cake cases as you may have noticed on the
posting yesterday about the oscilloscope I built.
Naturally, after prep comes the various stages of assembly. You start with
the lowest-height components, so here's the board after I fitted the ceramic
capacitors:
And here's after I fitted the lying-down electrolytic decoupling capacitor
for the 3.3 volt line:
Next I should have fitted the six transitors from the middle cake case, but I
discovered that I'd used the wrong pinout for them. Even after weeks of
verification by myself and others, I'd made a mistake. My good friend
Vincent Sanders recently posted about how creativity is allowing
yourself to make mistakes and here I had made a doozy I hadn't spotted until I
tried to assemble the board. Fortunately TO-92 transistors have nice long legs
and I have a pair of tweezers and some electrical tape. As such I soon had
six transistors doing the river dance:
With that done, I noticed that the transistors now stood taller than the
pins (previously I had been intending to fit the transistors before the pins)
so I had to shuffle things around and fit all my 0.1" pins and sockets next:
Then I could fit my dancing transistors:
We're almost finished now, just one more capacitor to provide some input
decoupling on the 9v power supply:
Of course, it wouldn't be complete without the ESP8266Huzzah I acquired
from AdaFruit though I have to say that I'm unlikely to use these again,
but rather I might design in the surface-mount version of the module instead.
And since this is the very first Beer'o'Meter to be made, I had to go and
put a 1 on the serial-number space on the back of the board. I then tried
to sign my name in the box, made a hash of it, so scribbled in the gap
Finally I got to fit all six of my flow meters ready for some testing. I may
post again about testing the unit, but for now, here's a big spider of a flow
meter for beer:
This has been quite a learning experience for me, and I hope in the future to
be able to share more of my hardware projects, perhaps from an earlier stage.
I have plans for a DAC board, and perhaps some other things.
What happened in the reproducible
builds effort between December
27th and January 2nd:
Infrastructure
dak now silently accepts and discards .buildinfo files (commit 1, 2), thanks to Niels Thykier and Ansgar Burchardt. This was later confirmed as working by Mattia Rizzolo.
Packages fixed
The following packages have become reproducible due to changes in their
build dependencies:
banshee-community-extensions,
javamail,
mono-debugger-libs,
python-avro.
The following packages became reproducible after getting fixed:
fltk1.1/1.1.10-20 by Aaron M. Ucko, currently FTBFS.
fltk1.3/1.3.3-5 by Aaron M. Ucko, currently FTBFS.
reproducible.debian.net
The testing distribution (the upcoming stretch) is now tested on armhf. (h01ger)
Four new armhf build nodes provided by Vagrant Cascandian were integrated in the infrastructer. This allowed for 9 new armhf builder jobs. (h01ger)
The RPM-based build system, koji, is now in unstable and testing. (Marek Marczykowski-G recki, Ximin Luo).
Package reviews
131 reviews have been removed, 71 added and 53 updated in the previous week.
58 new FTBFS reports were made by Chris Lamb and Chris West.
New issues identified this week:
nondeterminstic_ordering_in_gsettings_glib_enums_xml,
nondeterminstic_output_in_warnings_generated_by_breathe, qt_translate_noop_nondeterminstic_ordering.
Misc.
Steven Chamberlain explained in length why reproducible cross-building across architectures mattered, and posted results of his tests comparing a stage1 debootstrapped chroot of linux-i386 once done from official Debian packages, the others cross-built from kfreebsd-amd64.
Previously: 
Here is my monthly update covering what I have been doing in the free software world (
The second pre-conference day was dedicated to books and beers, with a visit to an exquisite print studio, and a beer tasting session at one of the craft breweries in Canada. In addition we could grab a view into the Canadian lifestyle by visiting Pavneet s beautiful house in the countryside, as well as enjoying traditional style pastries from a bakery.
If that wasn't all bad enough, now there is a new threat: while you are relaxing in the sun, scammers fool your phone company into issuing a replacement SIM card or transferring your mobile number to a new provider and then proceed to use it to take over all your email, social media, Paypal and bank accounts. The same scam has been appearing around the globe, from 
For phone companies, SMS messaging came as a side-effect of digital communications for mobile handsets. It is less than one percent of their business. SMS authentication is less than one percent of that. Phone companies lose little or nothing when SMS messages are hijacked so there is little incentive for them to secure it. Nonetheless, like insects riding on an elephant, numerous companies have popped up with a business model that involves linking websites to the wholesale telephone network and dressing it up as a "security" solution. These companies are able to make eye-watering profits by "purchasing" text messages for $0.01 and selling them for $0.02 (one hundred percent gross profit), but they also have nothing to lose when SIM cards are hijacked and therefore minimal incentive to take any responsibility.
Companies like Google, Facebook and Twitter have thrown more fuel on the fire by encouraging and sometimes even demanding users provide mobile phone numbers to "prove they are human" or "protect" their accounts. Through these antics, these high profile companies have given a vast percentage of the population a false sense of confidence in codes delivered by mobile phone, yet the real motivation for these companies does not appear to be security at all: they have worked out that the mobile phone number is the holy grail in cross-referencing vast databases of users and customers from different sources for all sorts of creepy purposes. As most of their services don't involve any financial activity, they have little to lose if accounts are compromised and everything to gain by accurately gathering mobile phone numbers from as many users as possible.
As some of the world knows full well by now, I've been noodling with Go
for a few years, working through its pros, its cons, and thinking a lot
about how humans use code to express thoughts and ideas. Go's got a lot of
neat use cases, suited to particular problems, and used in the right place,
you can see some clear massive wins.
I've started writing Debian tooling in Go, because it's a pretty natural fit.
Go's fairly tight, and overhead shouldn't be taken up by your operating system.
After a while, I wound up hitting the usual blockers, and started to build up
abstractions. They became pretty darn useful, so, this blog post is announcing
(a still incomplete, year old and perhaps API changing) Debian package for Go.
The Go importable name is 
There has been some silence on the 
In the ARM world, to which I am still mostly a newcomer (although I've been already playing with ARM machines for over two years, I am a complete newbie compared to my Debian friends who live and breathe that architecture), the most common way to distribute operating systems is to distribute complete, already-installed images. I have 
I am trying to get the best out of my Yubikey NEO by using as many of its functionality, in particular: Smartcard for my GNuPG keys, OTP similar to Google Authenticator and similar, as well as challenge-response for additional login security, as well as all that over NFC to not keep keys/passwords on my mobile phone.
While there are loads of guides (see the 
Challenge: I am currently searching for a method to replace the second factor of they key optionally with a different authentication method, like a very difficult passphrase. This way I could log in even without my key, but in this case would need the complicated passphrase. From my reading of the pam manuals it seems to be possible, and I am planning to use pam_ssh and a specific login key with a complicated passphrase. I will report back when this is done.
YubiOATH (TOTP) Time based One Time Passwords (aka Google Authenticator style)
Without any setup whatsoever this worked out of the box. I use the 
We're excited to announce that Debian has selected 29 interns to work with us
this summer: 4 in 
As some of you may know, I have been working on a small hardware project called
the Beer'o'Meter whose purpose is to allow us to extend 
What happened in the 
